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[57] ABSTRACT 

An improved credit card biUing method and system is 
disclosed which permits multiple items purchased as part of 
a single transaction or order to be separately billed on a 
credit card in accordance with a payment schedule designed 
to minimize inquiries regarding the overall order by the 
customer. The biUing system permits the billing descriptor 
appearing on the credit card billing statement to have 
sufficient detail to minimize subsequent customer inquiries. 
The billing descriptor preferably includes a different cus- 
tomer service number for each individual item. Goods or 
services are purchased from a merchant in a conventional 
maimer. The customer provides the merchant with a hst of 
the multiple items included in the order, as well as credit 
card information. The merchant wiU preferably establish a 
staggered schedule for billing each individual item in the 
order and submit the charge requests to the credit card issuer 
in accordance with the established billing schedule. 

18 Claims, 12 Drawing Sheets 
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CREDIT CARD BILLING METHOD AND Thus, the consumer's unfamiliarily with the name of the 

SYSTEM remote retailer, such as NewSub Services, may trigger a 

I7TCT T^ TTjp TXTT /cNm A^KT tclephonc chII to the indicated customer service number, to 

FIELD OF THE INVENTION ■ *: * i ■ * j 

mvcstigate the source or particulars associated with the 

The present invention relates generally to a credit card 5 charge. In addition, because all of the purchased goods and 
billing system used by retailers who sell goods or services, services are grouped together for billing purposes, the larger 
and more particularly, to an improved billing system which total amount indicated on the credit card billing statement 
facilitates the placement of charges for such goods or will receive additional scrutiny from the consumer. If a 
services on a credit card billing statement in such a manner consumer purchases multiple cancelable items on a credit 
as to reduce the likelihood that the customer will request 10 card, the aggregation of the cost of individual items into a 
further infonnation regarding the purchased goods or ser- total amount for billing purposes stimulates higher cancel- 
vices, lation rates for the remote retailer, especially as the total 
BACKGROUND OF THE INVENTION amount of the charges increases. In any event, once the 
^. , . , . o r .1. 1 consumer is on the phone with the customer service 
Direct markeung and other forms of remote retailing have organization, the consumer has an easy opportunity to cancel 
become effecUve tools m the sale of maay products and pu^hased goods or services. In addition, when all items 
ser^ces^ It has been found that direct marketing ^ particu- aggregated together in this manner, the consumer is more 
larly effective for seUmg certain types of products and ^j^^^ ,^ ^^^^ ^^^^^^ ^^^^^ ^ ^ ^^^^ 
services, including magazme subscriptions and membership (otal amount, rather than just canceling one or more indi- 
services, as evidenced by the succe^ of such direct mar- ^ ^^^^ ^^^^ components of the total 
Kcting companies as NewSub Services and CUC charec 

International, each of Stamford, Conn, ." , . , . ^ 

. . * . 1 • 11 1 ■ While many merchants of^er installment and/or deferred 

Even when such remote retailers are initially successful in , , . ^ - , , , . . .1 

. J . ^ , . • J J/ biUmg plans, such conventional plans do not permit the 

inducing a consumer to purchase certain goods and/or u * * * 1 u-n * c l • _i- -j 1 

. ft , J tfi ,1- * * f merchant to separately bill a customer for each individual 

services, often at considerable expense, the remote nature of ^- v . J c i.- 1 j r -i-.- 

. ^- ir • 1 J- 1 L ^ item purchased as part of a multiple-item order. In addition, 

the transaction itseli, including the time lapse between the ,^ ^. t • , n ^ jjr j i_n- 1 j 

, J 1- J un- * * J * * such conventional mstalmient and deferred billing plans do 

purchase, delivery and billing events, tends to promote , , . - 1 ■ j- -j 1 -.u- 

ft J • /» 7 £ ,1. u *u not stagger the billing or such individual items within an 

second guessing on the part of the consumer when the n j 1. .1. . .1. n • . ^ -.t 

\i u n- * + * £ 11 • -ru overall order, such that the smaller amount associated with 

credit card billing statement finally arrives. Thus, many l • j- j 1 • j- . j i- .1 -i.- 

,1 . L- u Hi- / ^acli individual item indicated on the credit card bilhng 

remote retailers expenence a very high cancellation rate. ,n . * . n u • * j -.l l j 

„ 4 . -i- r u u- • f 1 statement will be interspersed with other purchases and 

Remote retailing of membership services, for example, can .i.. • .j .-r 

n , . ^ , . u * c thereby receive reduced scrutiny from the consumer, 
exhibit cancellation rates as high as fifty percent (50%) of ... 
total charges. ^ apparent from the above deficiencies with conven- 
Cbnsumers often purchase such goods or services with a ^^^^^l ^T^^^^ ^^^^ ^^^^^ ^ys^i^ms., a need exists for a credit 
limited understanding of the cost, or to obtain a free incen- 35 ^^^^^"^ produces a credit card bilhng 
tive being offered by the remote retaUer to induce the statement having improved bilhng mformation thereby 
purchase of the goods or services. Thus, when the charge for ^/^^^^^^ likelihood that a consumer will call the retailer 
the purchased goods or services ultimately appears on the for customer service purposes. A further need exists for a 
consumer's credit card billing statement, the consumer often ""l^^'^ ^^^^ ^jllmg system that permits a retailer to break up 
questions the purchase. .n ""^^^^^ mdividual hne items for billmg 
. . ^ J ^ . -1 purposes, each havine a description of the associated prod- 
When a charge is made to a credit card, remote retailers ^ / J JVCC ^ . • L 
, • 11 • 1 J . n r , ' * 1 L ^ct and a dinerent customer service number, 
typically include a toll-free customer service telephone 

number, as part of the information printed on the credit card SUMMARY OF THE INVENTION 
billing statement, together with the merchant name, a 

description of the goods purchased and the total cost of the 45 Generally, according to one aspect of the invention, a 

goods. In this manner, inquiries about the charge may be customer who purchases multiple cancelable items as part of 

directed to the appropriate merchant, as opposed to the credit a single transaction or order from a merchant will be 

card issuer, and the remote retailer may thereby have an separately billed on an account for each individual good or 

opportunity to "save the sale." Upon receipt of the credit service in accordance with a payment schedule designed to 

card billing statement, and seeing the total charge for the 50 minimize canceUation of the overall order by the customer, 

purchased goods or services, consumers will often "second According to a further feature of the present invention, the 

guess" their initial ptu-chase, and call the indicated ctistomer billing descriptor which ultimately appears 00 the credit card 

service number to cancel the purchased goods or services. billing statement of the customer will have sufficient detail 

The tendency of the consumer to "second guess" their to minimize the likefihood that the customer will subse- 

initial purchase is often compounded by the consumer's 55 quently contact the merchant to investigate the source of the 

un familiarity with the name of the remote retailer. In charge. In one preferred embodiment, the billing descriptor 

addition, this tendency is further compounded by the indus- will include a different customer service number for each 

try practice of aggregating all of the individual goods and individual item encouraging the customer to focus on indi- 

services purchased at a single time for billing purposes and vidual understandable items instead of one amorphous bill, 

providing a generic description of the purchased goods and 60 A customer purchases a plurality of goods or services 

services, such as "magazines" or "membership services", from a merchant in a conventional manner. As part of the 

with an aggregate amount for all of the purchased goods and transaction between the customer and the merchant, the 

services. For example, a consumer who orders an annual customer will provide the merchant with a list of the 

subscription to Time magazine and People magazine for $15 multiple cancelable items included in the order, as well as 

and $2S, respectively, from NewSub Services, might see a 65 credit card information. After the merchant has received an 

total charge for S43 from NewSub Services labeled "Maga- approval for the credit card purchase from the credit card 

zines" on the consumer's credit card billing statement. issuer, the merchant will fulfill the order to the customer. 
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In accordance with a feature of the present invention, the 
merchant will preferably implement a charge cancellation 
reduction process to establish a staggered billing schedule 
for each item in the order. The established schedule is 
preferably stored in a billing schedule database. The can- 
cellation reduction process permits multiple cancelable 
items purchased as part of a single order to be separately 
billed on a credit card. In one embodiment, the billing 
schedule delays billing of each item until at least one item 
is initially received by the customer and thereafter staggers 
the billing of each remaining item by a predefined period. 

Thus, in order to receive payment for the purchased goods 
or services, the merchant transmits a charge request com- 
munication to a credit card issuer for each item, typically via 
a third party credit card processor, in accordance with the 
estabhshed billing schedule. The data transmitted by the 
merchant to the credit card issuer typically includes a 
merchant identification number, the detailed billing 
descriptor, customer credit card number, and the purchase 
amount. In one embodiment, the billing descriptor prefer- 
ably includes an indication of the reference number associ- 
ated with the customer's order, the name of the merchant, a 
detailed product descriptor identifying the individual item, 
and a customer service telephone number unique to the item. 

Upon receipt of the charge information, the credit card 
issuer initially evaluates the credit card number to determine 
whether the received number is a valid number, and there- 
after determines whether the purchase price is within the 
pre-established available credit limits for the customer's 
account. If the purchase price is within the pre-established 
available credit limit for a valid customer account, the credit 
card issuer then deducts the amount from the available credit 
limit, and transmits an authorization number back to the 
merchant, via the credit card processor. The credit card 
issuer wUl then initiate the transfer of the purchase amount, 
less a handling fee, to the pre-established merchant account 
at the merchant's bank. 

A more complete understanding of the present invention, 
as well as further features and advantages of the present 
invention, will be obtained by reference to the following 
detailed description and drawings. 

BRIEF DESCRIPTION OF DRAWINGS 

FIG. 1 is a schematic block diagram illustrating a suitable 
communications network for interconnecting the various 
parties participating in a retailing transaction; 

FIG. 2 is a schematic block diagram of a processor which 
may be utilized by the credit card issuer of FIG. 1; 

FIG. 3 is a schematic block diagram of a processor which 
may be utilized by the merchant of FIG. 1; 

FIG. 4 illustrates a sample table from the credit card 
customer database of RG. 2; 

FIG. 5 illustrates a sample table from the transaction 
database of FIG. 2; 

FIG. 6 illustrates a sample table from the fulfillment 
database of FIG. 3; 

FIG. 7 illustrates a sample table from the bHUng schedule 
database of FIG. 3; 

FIG. 8 illustrates a sample table from the product iden- 
tification database of FIG. 3; 

FIG. 9 is a flow chart describing an overview of exem- 
plary processes according to the present invention; 

FIGS. lOAand lOB, collectively, are a flow chart describ- 
ing an exemplary cancellation reduction process; and 

FIG. 11 is a flow diart describing an exemplary biUing 
process. 
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DETAILED DESCRIPTION 

FIG. 1 shows an illustrative network environment for 
transferring transactional information between the parties 
that typically participate in the purchase of goods or 
^ services, including a customer 10, a merchant 20, and one or 
more banks or credit card issuers, such as a merchant bank 
50 and a credit card issuer 40. While the illustrative embodi- 
ment is described in the context of a remote retaihng 
environment, it is noted that goods or services purchased in 
a traditional point-of-sale environment are within the scope 
of the present invention as well. 

A remote retailing transaction, as used herein, is any 
transaction outside of the traditional point-of-sale environ- 
ment. A remote retailing transaction includes piu^chases of 
goods or services, such as magazine subscriptions, mem- 
bership services or catalog purchases, made by a customer 
10 from a merchant 20, such as a direct merchant, remotely 
via, for example, telephone, mail, the Internet, or a shared 
revenue service, such as a 900 or a 976 telephone number 
service. 

As shown in FIG. 1, a customer 10 purchases a plurality 
of goods or services from a merchant 20 in a conventional 
manner. As part of the transaction between the customer 10 

25 and the merchant 20, the customer 10 will provide the 
merchant 20 with a list of the multiple cancelable items 
included in the order, as well as credit card information. 
After the merchant 20 has received an approval for the credit 
card purchase fi:om the credit card issuer 40, in the maimer 

30 described below, the merchant 20 wiU fulfill the order to the 
customer 10. It is noted that the merchant 20 can directly 
fulfill the order to the customer 10, by delivering the goods 
or services to the customer 10. Alternatively, the merchant 
20 can indirectly fulfill the order to the customer 10, by 

35 using a third party fulfillment house 60 to deliver the goods 
or services to the customer 10, as shown in FIG. 1. When the 
order is fulfilled by a third party fulfillment house 60, the 
merchant 20 will typically only provide the customer 10 
with a confirmation of the order. 

40 As discussed further below in conjunction with FIGS. 9 
through 11, a customer 10 who purchases multiple cancel- 
able items as part of a single transaction or order from a 
merchant 20 will be separately billed on a credit card for 
each individual good or service in accordance with a pay- 

45 ment schedule designed according to a feature of the present 
invention to minimize cancellation of the overaU order by 
the customer 10. According to a further feature of the present 
invention, the bilhng descriptor which ultimately appears on 
the credit card biUing statement of the customer 10 wiU have 

50 sufficient detail to minimize the likelihood that the customer 
10 will subsequently contact the merchant 20 to investigate 
the source of the charge. In one preferred embodiment, the 
billing descriptor will include a different customer service 
number for each individual item so that the customer 10 

55 cannot cancel the entire order with a single telephone call. 
With respect to credit card processing of the individual 
purchased items, the merchant 20 and the credit card issuer 
40, such as Citibank \^sa, operate in a conventional matmer, 
typically utilizing a third party credit card processor 30, such 

60 as First USA Paymentech of Salem, N.H. In order to receive 
payment for the purdiased goods or services, the merchant 
20 transmits a communication to the credit card issuer 40, 
via the credit card processor 30, as shown in FIG. 1. The 
merchant 20, credit card processor 30 and credit card issuer 

65 40 transmit digitally encoded data and other information 
between one another. The communications link between the 
merchant 20, credit card processor 30 and credit card issuer 
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40 preferably comprises a cable or wireless link on which The communications port 260 conaects the credit card 

electronic signals can propagate. issuer 40 to a network interface 270, thereby linking the 

-Die data transmitted by the merchant 20 to the credit card credit card issuer 40 to the merchant 20, via the credit card 

issuer 40 typically includes a merchant identification processor 30, and to one or more merchant banks 50, In 
number, a billing descriptor, customer credit card number, s addition, the communications port 260 may optionally con- 

and the purchase amount. As discussed further below, the nect the credit card issuer 40 to a pnatcr 280, which may be 

bilHng descriptor preferably includes an indication of the utilized, among other things, to pnnt credit card billing 

reference number associated with the customer's order, the statements. The communications port 260 preferably 

name of the merchant 20, a detailed product descriptor includes multiple communication channels for simulta- 
identifying the individual item, and a customer service lo neously connectmg the credit card issuer 40 with multiple 

telephone number. The credit card number identifies the type parties, 

of credit card, the issuing bank, and the cardholder's FIG. 3 is a block diagram showing the architecture of an 

account, in a known manner. Thus, based on the credit card illustrative processor 300 which may be utilized by the 

number, the credit card processor 30 can identify the appro- merchant 20. The processor 300 preferably includes certain 
priate credit card issuer 40 to contact for authorization. 15 standard hardware components, such as a central processing 

Upon receipt of the charge information, the credit card ^nit (CPU) 310, a data storage device 320, a read only 

issuer 40 initially evaluates the credit card number to memory (ROM) 330, a random access memory (RAM) 340, 

determine whether the received number is a valid number, a clock 350, and a commumcations port 360. The CPU 310 

and thereafter determines whether the purchase price is is preferably linked to each of the other listed elements, 

within the pre-established available credit Umits for the either by means of a shared data bus, or dedicated 

customer's account. If the purchase price is within the connecUons, as shown in FIG. 3. 

pre-established available credit limit for a valid customer The CPU 310 may be embodied as a single processor, or 
account, the credit card issuer 40 then deducts the amount a number of processors operating in parallel, in the manner 
from the available credit limit, and transmits an authoriza- described above for the CPU 210 in conjunction with FIG. 
tion number back to the merchant 20, via the credit card 2. The data storage device 320 and/or ROM 330 are operable 
processor 30. The credit card issuer 40 will then initiate the to store one or more instructions, as discussed below in 
transfer of the purchase amount, less a handling fee, to the conjunction with FIGS. 9 through 11, which the CPU 310 is 
pre-established merchant account at the merchant bank 50. operable to retrieve, interpret and execute. As discussed 
HG. 2 is a block diagram showing the architecture of an „ ^irther below in conjunction with FIGS. 6 through 8 and 
illustrative processor 200 which may be utilized by the FIG. 10, respectively, the data storage device 320 preferably 
credit card issuer 40. The processor 200 preferably includes includes a fulfillment database 600, a biUing schedule data- 
certain standard hardware components, such as a central base 700, a product identification database 800 and a can- 
processing unit (CPU) 210, a data storage device 220, a read cellation reduction process 1000. The fulfillment database 
only memory (ROM) 230, a random access memory (RAM) 600 preferably stores information on each order received by 
240, a clock 250, and a communications port 260. The CPU the merchant 20, including the biUmg terms associated with 
210 is preferably Imked to each of the other listed elements, each order. The billing schedule database 700 preferably 
either by means of a shared data bus, or dedicated stores the biUing schedule used by the merchant 20 to 
connections, as shown in FIG. 2. stagger the billing for each item included within a given 
^ r^TMi^^n u u J- J -1 order, in accordance with the present invention. The product 
The CPU 210 may be embodied as a smgle processor, or 40 . i. onn r ui . ■ r 

. c ■ 11 1 Tn, ^ * identification database 800 preferably stores mformation on 

a number of processors operatme in parallel. The data , , 1 , , , . ■ 1 j- j 

J ^-in A I i^n ui * * each p 10 duct sold by the merchant 20, includmg a dcscnp- 

storage device 220 and/or ROM 230 are operable to store . ..r uj* 

. , J. J t_ 1 • • tion and cost for each product, 

one or more instructions, as discussed below in conjunction ^ 

with FIGS. 9 through 11, which the CPU 210 is operable to The communications port 360 connects the merchant 20 
retrieve, interpret and execute. The CPU 210 preferably 45 to a network interface 370. thereby Hnking the merchant 20 

includes a control unit, an arithmetic logic unit (ALU), and to the credit card issuer 40, via the credit card processor 30. 

a CPU local memory storage device, such as, for example. The communications port 360 preferably includes multiple 

a stackable cache or a plurahty of registers, in a known communication channels for simultaneously connecting the 

manner. The control unit is operable to retrieve instructions merchant 20 with multiple parties. 

from the data storage device 220 or ROM 230. The ALU is 50 As previously indicated, the credit card customer database 

operable to perform a plurality of operations needed to carry 400, shown in FIG. 4, preferably stores biographical infor- 

out instructions. The CPU local memory storage device is mation on each customer account maintained by the credit 

operable to provide high speed storage used for storing card issuer 40, as well as the credit limit associated with each 

temporary results and control information. credit card account. The credit card customer database 400 
As discussed further below in conjunction with FIGS. 4 55 maintains a plurahty of records, such as records 410-^13, 

and 5, respectively, the data storage device 220 preferably each associated with a different credit card customer. For 

includes a credit card customer database 400 and a transac- each customer credit card number listed in field 420, the 

tion database 500. The credit card customer database 400 credit card customer database 400 includes the name and 

preferably stores biographical information on each address of the customer m fields 425 and 430, respectively, 
customer, as well as the credit limit associated with each 60 la addition, the credit card customer database 400 preferably 

credit card account. Tlie transaction database 500 preferably includes an indication of the card cxpu-ation date m field 435 

stores information required by the credit card issuer 40 for and an indication of the credit Hmit associated with the 

each transaction made by a customer 10, including the account in field 440. 

received billing descriptor and purchase amount for each As previously indicated, the transaction database 500, 
item. The information stored in the transaction database 500 65 shown in FIG. 5, preferably stores information required by 

may be utilized by the credit card issuer 40 to generate the the credit card issuer 40 for each transaction made by a 

credit card billing statements, customer 10 using their credit card account, including the 
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received billing descriptor and purchase amount for each 
purchase. The transaction database 500 naaintains a plurality 
of records, such as records 510-513, each associated with a 
different credit card transaction. For each transaction, the 
transaction database 500 preferably stores the date, time, 
credit card number and order reference number associated 
with the transaction in fields 520, 525, 530 and 535, respec- 
tively. In addition, the transaction database 500 includes the 
billing descriptor, merchant identification code and purchase 
amount associated with the transaction in fields 540, 545 and 
550, respectively, as received from the merchant 20. Finally, 
the transaction database 500 includes an indication of the 
authorization code in field 555 which the credit card issuer 
40 has generated for the transaction and transmitted to the 
merchant 20. The credit card issuer 40 can sort the transac- 
tion database 500 by credit card number, in order to generate 
the credit card billing statements. 

In accordance with a feature of the present invention, the 
billing descriptor stored in field 540, as received from the 
merchant 20, may be customized and of suf&cient detail to 
reduce the likelihood that the customer will contact the 
merchant 20 to question the source of the charge. In 
addition, the billing descriptor preferably includes an indi- 
cation of the reference number associated with the custom- 
er's order, the name of the merchant 20, a detailed product 
descriptor identifying the individual item, and a customer 
service telephone number. In one preferred embodiment, the 
billing descriptor will include a different customer service 
number for each individual item so that the customer 10 
cannot cancel the entire order with a single telephone call. 

As previously indicated, the fulfillment database 600, 
shown in FIG. 6, preferably stores information on each order 
received by the merchant 20, including the biUing terms 
associated with each order. The falfillment database 600 
maintains a plurality of records, such as records 610-613, 
each associated with a different item of each multi-item 
purchase order. The fulfillment database 600 preferably 
stores the order reference number associated with each item, 
as well as the order date, customer name and address, credit 
card number and related expiration date, associated with 
each item in fields 620, 625, 630, 635, 640 and 645, 
respectively. In addition, the fulfillment database 600 pref- 
erably stores the authorization code received back from the 
credit card issuer 40 in field 650. Finally, the fulfilhnent 
database 600 preferably stores a product description of each 
item in field 655, and the billing terms and renewal date, if 
applicable, in fields 660 and 665. Thus, the fulfilhnent 
database 600 maintains any information required by the 
merchant 20 to respond to customer service inquiries. 

Tlie billing terms stored in the fulfillment database 600 
may include an indication of the amount and frequency of 
each installment payment to be diarged for each item. The 
renewal date, if applicable, is preferably based on the initial 
anticipated delivery date of the goods or services. In this 
manner, the renewal date may be utifized to renew any 
continuous subscription-based goods or services until can- 
celed by the customer 10 and to initiate the establishment of 
an appropriate staggered billing schedule for payments 
associated with such renewal periods, as would be apparent 
to a person of ordinary skill. 

As previously indicated, the billing schedule database 
700, shown in FIG. 7, preferably stores the billing schedule 
used by the merchant 20 to stagger the billing for each item 
included within a given order, in accordance with principles 
of the present invention. The bilhng schedule database 700 
maintains a plurality of records, such as records 710-713, 
each associated with a different billing transaction. In a 



16,205 

8 

preferred embodiment, each billing transaction corresponds 
to one item, or installment payment of an item, of a 
multi-item purchase order. The billing schedule database 
700 is preferably indexed by the scheduled authorization 

5 date of each billing transaction listed in field 720. For each 
billing transaction Hsled in field 720, the billing schedule 
database 700 preferably records the associated order refer- 
ence number, order date, customer name and address, credit 
card number and related expiration date and amoimt asso- 
ciated with each billing transaction in fields 725, 730, 735, 
740, 745, 750 and 755, respectively. 

In addition, the billing schedule database 700 preferably 
records a detailed billing descriptor in field 760 which 
should be transmitted to the credit card issuer 40 with the 
authorization request for printing on the customer's credit 
card billing statement. As previously indicated, the billing 
descriptor preferably includes an indication of the reference 
number associated with the customer's order, the name of 
the merchant 20, a detailed product descriptor identifying 
the individual item, and a customer service telephone num- 

20 ber that is unique for each item. Finally, the billing schedule 
database 700 preferably stores the authorization code in field 
765 for verification purposes that is received back from the 
credit card issuer 40. 
As previously indicated, the product identification data- 

25 base 800, shown in FIG. 8, preferably stores information on 
each product sold by the merchant 20, including a descrip- 
tion and cost for each product. The product identification 
database 800 maintains a plurality of records 810-813, each 
associated with a different product sold by the merchant 20. 

30 For each product sold by the merchant 20, identified by 
product identification number in field 820, the product 
identification database 800 preferably stores a product 
descriptor, a customer service ntunber and an amoimt or cost 
of the product in fields 825, 830 and 835, respectively. It is 

35 noted tbat a merchant 20 can implement a different cost for 
a particular product as part of two different marketing 
campaigns by assigning two different product identification 
numbers to the product, each having a different associated 
amount or cost. 

40 The product descriptors and ctistomer service numbers are 
preferably utUized by the merchant 20 to construct the 
bilhng descriptors. As previously indicated, the billing 
descriptors may be customized by the merchant 20 and of 
sufficient detail to reduce the likelihood that a customer 10 

45 will subsequently contact the merchant 20 to question the 
source of the charge. In addition, as previously indicated, a 
different customer service number is preferably utilized by 
the merchant 20 for each individual item purchased by a 
customer 10 so that the customer 10 cannot cancel the entire 

50 order with a single telephone call. 

As discussed further below in conjunction with FIGS. 9 
through 11, the processes performed in accordance with the 
present invention permit a customer 10 who purchases 
multiple cancelable items as part of a single transaction or 

55 order firom a merchant 20 to be separately biQed for each 
individual good or service, in accordance with a payment 
schedule designed to minimize cancellation of the overall 
order by the customer 10. In addition, the present invention 
permits the billing descriptor associated with the charge 

60 which appears on the credit card billing statement of the 
customer 10 to provide sufficient detail to minimize the 
likeHhood that the customer 10 wiU contact the merchant 20 
to investigate the source of the charge. In one preferred 
embodiment, the biUing descriptor will include a different 

65 customer service number for each individual item so that the 
customer 10 cannot cancel the entire order with a single 
telephone call. 
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As illustrated in FIG. 9, the processes embodying the value of the variable, scheduled authorization date, is placed 

principles of the present invention will begin during step in the entry m field 720. 

910 when a customer, such as the customer 10, purchases A test is performed during step 1025 to determme whether 

multiple goods or services from a remote merchant and additional instaUment payments are required for the current 

provides a credit card number as a method of payment. It is 5 item. For example, the merchant 20 can access the bilhng 

noted that the purchase may be part of a traditional point- terms stored in field 660 of the fulfilhnent database 600 to 

of-sale transaction, wherein the customer 10 and merchant determine if the current item should be billed on an install- 

20 may communicate face-to-face, or a remote retailing ment basis. 

transaction. Thereafter, during step 920, the merchant 20 if ^ is determined during step 1025 that additional install- 
will transmit its merchant identification number, billing 10 ment payments are required for the current item, then the 

descriptor, total purchase amount and credit card informa- merchant 20 will preferably create additional entries in the 

tion to the credit card issuer 40 for pre-authorization. It is billing schedule database 700 for each further required 

noted that the total amount of the entire order is preferably installment payment (step 1030). Specifically, the additional 

submitted for pre-authorization with a generic billing entries associated with each farther required installment 
descriptor generally identifying all of the items included in 15 payment will have an appropriate billing descriptor placed in 

the order. the entry in field 760 and a scheduled authorization date 

After the merchant 20 receives an appropriate authoriza- placed in the entry in field 720 equal to the current value of 

tion during step 930 fi:om the credit card issuer 40, the the variable, scheduled authorization date, plus an appropn- 

merchant 20 wiU preferably fulfiU the entire order during ate offset, based on the instalbnent periods. It is noted that 

step 940 and create a record of the order in the fulfillment it may be desirable to establish a different customer service 

database 600 in the manner described above in conjunction number for subsequent installment payments than was asso- 

with FIG 6.' The merchant 20 will preferably place the ciated with the initial installment, so that special handling, 

authorization code received during step 930 in the entry in tailored to the installment number, may be implemented 

field 650 for each item in the current order. upon a customer inquiry to the customer service number. 

As discussed further below in conjunction with FIGS. If, however, it is determined during step 1025 that addi- 

lOA through lOB, the merchant 20 wiU preferably execute tional installment payments are not required tor «ie/"^rren 

a cancellation reduction process 1000 during step 950 to item, then program control will proceed to step 1035. A test 

establish a payment schedule for each item in the order. The is performed during step 1035 to determme if there are 

payment schedule established during step 950 is preferably additional items to be processed m the current order, 

stored in the billing schedule database 700 (FIG. 7). As If it is determined during step 1035 that there are addi- 

previously indicated, the cancellation reduction process tional items to be processed in the current order, then 

1000 permits a customer 10 who purchases multiple can- program control will proceed to step 1040 (FIG. lOB) for 

celable items as part of a single transaction or order from a processing of the subsequent items. If, however, it is deter- 

merchant 20 to be separately billed on a credit card for each mined during step 1035 that there are no additional items to 

individual good or service in accordance with a payment be processed in the current order, then program control will 

schedule designed to minimize cancellation of the overall terminate. 

order by the customer 10. A further test is performed during step 1040 to determine 

Finally, as discussed below in conjunction with FIG. 11, if the current item number, within the total number of items 

the merchant wiU execute a biUing process during step 960 in the given order, exceeds a predefined number. As dis- 

to facilitate the transmission of its merchant identification cussed further below in conjunction with step 1055, the test 

number, billing descriptor, item purchase amount and credit performed during step 1040 is designed to ensure that the 

card information to' the credit card issuer 40 for each overaU billing period stays within a predefined limit, 

individual item in the billing schedule database 700 in [f it is determined during step 1040 that the current item 

accordance with the payment schedule established during number does not exceed the predefined minimurn number, 

the previous step. then the process will continue processing the next item in the 

As previously indicated, the merchant 20 will preferably current order. Thus, the variable, scheduled authorization 

execute a cancellation reduction process 1000, shown in date, will be incremented during step 1045 by the value of 

FIGS lOAthroughlOB, to establish a payment schedule for a second variable, stagger period. The vanable, stagger 

each item in a given order. As shown in FIG. lOA, the 50 period, is intended to separate billing of each item withm the 

merchant 20 will initially access the fiilfillment database 600 order by a predefined penod. Thereafter, the merchant 20 

during step 1010 and retrieve the multiple items constituting will update the index in the fulfilhnent database durmg step 

a given order Thereafter, the merchant 20 will define a 1050 to retrieve the next item in the current order from the 

variable scheduled authorization date, during step 1015 to fulfillment database 600 for processing. Program control 

be equal to the current date plus a predefined delay period. 55 will then return to step 1020 for processing of the next item. 

In this manner, if desired, the merchant 20 can ensure that a in the manner described above. 

customer 10 is not billed for the transaction until at least a [f^ however, it is determined during step 1040 that the 

portion of the purchased goods or services are received. current item number does exceed the predefined minimum 

Thereafter, the merchant 20 will select the first item from the number, then the merchant 20 will limit the overall billing 

order for processing during step 1018. 60 period for which items associated with a given order may be 

The merchant 20 will create an entry in the biUing billed during step 1055 or otherwise prevent a customer 10 

schedule database 700, during step 1020, for an instaUment firom taking advantage of the staggered billmg process when 

payment of the current item of the given order. Hius, an an unusuaUy large number of items are purchased. In 

appropriate billing descriptor, constructed based on infor- particular, the merchant 20 may desire to bmit numbe 

rnation retrieved from the product identification database 65 of items wMch may have staggered bmmg so Uiat bdl^^ 

800, in the manner described above, is placed in the entry in all items is completed withm a predefined penod. For 

field 760 of the billing schedule database 700 and the current example, if a merchant defines the vanable, delay penod, to 
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be 60 days to ensure that the first item is not billed until the 
first item is actually received by the customer 10, and defines 
the variable, stagger period, to be 10 days to ensure that the 
bill for each item on the customer's credit card billing 
statement is separated by 10 days, theo if a particular s 
customer purchases 8 or more items, then item number 8 
will not be billed for 140 days. 

Thus, in order to ensure that the overall billing period 
stays within desired hmits, the merchant may desire to 
aggregate all remaining items during step 1055 for billing as 
a single transaction. Alternatively, when a large number of 
items arc purchased by a customer as part of a single order, 
the merchant 20 may desire to reduce the value of one or 
both of the variables, delay period or stagger period, so that 
the overall billing period stays within desired limits. 

In the illustrative embodiment, the credit card processor 
30 will thus aggregate all of the remaining items, above the 
predefined minimum number, during step 1055 for billing in 
one billing transaction. Program control wiU then retum to 
step 1020 for processing of this final aggregated item, in the 
manner described above. 

As previously indicated, the merchant 20 will execute a 
billing process during step 960 of the overall process to 
facilitate the transmission of its merchant identification 
number, billing descriptor, item purchase amount and credit 
card information to the credit card issuer 40 for each 
individual item in the billing schedule database 700 in 
accordance with the established payment schedule. 

As shown in FIG. 11, the merchant 20 will preferably sort 
the billing schedule database 700 during step 1110, by the 
scheduled authorization date field. In this manner, all of the 
billing items to be processed on each day will appear 
together. Thereafter, the merchant wOl transmit its merchant 
identification code, billing descriptor, item purchase amount 
and credit card information to the credit card issuer 40 for all 35 
entries in the sorted bOling schedule database 700 having a 
scheduled authorization date equal to the current date. 

A test is then performed during step 1130 by the credit 
card issuer 40 to determine if the credit card number is vaKd 
and if the purchase amount is within the available credit 40 
limit associated with indicated accotmt. If it is determined 
during step 1130 that the purchase amount is not within the 
available credit limit associated with a vaUd indicated 
account, a rejection of the transaction will be transmitted by 
the credit card issuer 40 during step 1140 to the merchant 20. 45 

If, however, it is determined during step 1130 that the 
purchase amoimt is within the available credit limit associ- 
ated with a valid indicated account, the credit card issuer 40 
will block off the credit in the account during step 1150 and 
transmit an authorization code to the merchant 20 during 50 
step 1160. The credit card issuer 40 wiU thereafter initiate a 
transfer of the purchase amount, less a handling fee, during 
step 1170 to an account associated with the merchant 20 at 
the merchant bank 50. Finally, the merchant 20 will update 
the entry in field 765 of the bilhng schedule database 700 for 55 
the current item during step 1180 with the authorization code 
received from the credit card issuer 40 during step 1160. 

It is to be understood that the embodiments and variations 
shown and described herein are merely iUtistrative of the 
principles of this invention and that various modifications 60 
may be implemented by those skilled in the art without 
departing from the scope and spirit of the invention. 

We claim: 

1. A method of processing a plurality of charges to an 
account for a purchase by a customer of a plurahty of items 65 
during a single transaction, said method performed over a 
communications network and comprising the steps of: 
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receiving an authorization request from a merchant to 
allocate a block of credit associated with said account 
for a total cost corresponding to said purchase; 

providing said merchant with an authorization code for 
said purchase in response to said authorization request; 

receiving a plurality of charge requests from said 
merchant, each of said charge requests associated with 
a different one of said plurality of items of said pur- 
chase; 

generating an account statement for said customer sepa- 
rately listing each of said charge requests associated 
with one of said items; and 

transmitting said account statement to said customer. 

2. The method according to claim 1, wherein said autho- 
rization request is at least equal to the total cost of said 
purchase. 

3. The method according to claim 1, further comprising 
the step of receiving a product descriptor associated with 
each of said charge requests and wherein said step of 
generating an account statement includes the step of printing 
said product descriptor associated with each of said items. 

4. The method according to claim 1, fiirther comprising 
the step of transferring the cost of said purchase to an 
account associated with said merchant less any handling fee. 

5. The method according to claim 1, wherein said plurality 
of charge requests each include an idenrifier for said 
account, a purchase price for said item, and a merchant 
identifier. 

6. The method according to claim 1, wherein said plurality 
of charge requests are staggered by a predefined period. 

7. The method according to claim 1, further comprising 
the step of fulfilling said purchase when said merchant 
receives said authorization code. 

8. The method according to claim 1, wherein said step of 
receiving a plurality of charge requests is delayed at least 
until said customer has received at least one of said items of 
said purchase, 

9. The method according to claim 1, wherein said step of 
receiving said plurality of charge requests comprises receiv- 
ing said plurality of charge requests for said one or more of 
said items of said purchase in accordance with an install- 
ment payment schedule established by said merchant, 

10. The method according to claim 1, wherein said step of 
receiving said plurality of charge requests is performed in 
accordance with a schedule, established by said merchant, to 
separately bill said customer for each of said items of said 
purchase. 

11. A device for processing over a communication 
network, a plurality of charges to an account for a purchase 
by a customer of a plurafity of items during a single 
transaction, the device comprising: 

a storage device; and 

a processor comiected to the storage device; 

the storage device storing a program for controlling the 
processor; and 

the processor operative with the program to: 

receive an authorization request from a merchant to 
allocate a block of credit associated with said account 
for a total cost corresponding to said purchase; 

provide said merchant with an authorization code for said 
purchase in response to said authorization request; 

receive a plurality of charge requests from said merchant, 
each of said charge requests associated with a different 
one of said pltu-ality of items of said purchase; 

generate an account statement for said customer sepa- 
rately listing each of said charge requests associated 
with one of said items; and 
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transmit said account statement to said customer 

12. The device according to claim 11, wherein said 
authorization request is at least equal to the total cost of said 
purchase. 

13. The device according to claim 11, wherein the pro- 
cessor is fiirther operative to receive a product descriptor 
with each of said charge requests and wherein the account 
statement includes said product descriptor associated with 
each of said items. 

14. The device according to claim 11, wherein the pro- 
cessor is further operative to transfer the cost of said 
purchase to an account associated with said merchant less 
any handling fee. 

15. The device according to claim 11, wherein said 
plurality of charge requests each include an identifier for 
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said account, a purchase price for said item, and a merchant 
identifier. 

16. The device according to claim 11, wherein said 
plurality of charge requests are staggered by a predefined 

5 period. 

17. The device according to claim 11, wherein receipt of 
said plurality of charge requests is delayed at least until said 
customer has received at least one of said items of said 
purchase. 

10 18. The device according to claim 11, wherein receipt of 
said plurahty of charge requests is scheduled in accordance 
with an installment payment schedule established by said 
merchant. 

i|< 4. )»> If « 
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